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Executive  Summary 


This  research  was  sponsored  by  the  Office  of  Naval  Research 
and  was  directed  at  understanding  and  improving  systems  design 
procedures  in  support  of  Department  of  Defense  surface 
transportation  and  traffic  management. The  primary  focal  point  of 
the  research  was  Military  Sealift  Command  (MSC)  operations  and 
their  interfaces  with  the  Military  Traffic  Management  Command 
(MTMC) ^ 


In  Section  1  we"iHscuss  the  objectives  and  scope  of  this 
research.  0^  describe  surface  transportation 
activities  and  supporting  management  systems  through  a  horizontal 
view  (the  logistics  supply  chain  and  its  associated  agencies)  and 
a  vertical  view  (the  strategic,  tactical,  and  operational  decision 
processes  for  planning  and  control) we  consider 
the  operational  level  in  more  detail  and  describe  basic  processes 
and  systems  associated  with  cargo  traffic  management.  This 
provides  a  perspective  on  the  problems  of  horizontal  data  and 
system  integration  across  the  several  agencies  and  processes 


supporting  cargo  traffic  management.^  Seagtoa^ir^  we  discuss 

design  and  implementation  issuesfl,  “The  key  issue  is  the  degree  of 
(de)centralization  of  control/responsibility  for  design, 

development,  and  data  specification  within  and  among  agencies  in 

P  C  ('  ; 

the  transportation  and  deployment  community.  &£& i we 

summarize  several  pressing  problems  with  the  current  state  of 


/ 
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defense  transportation  systems  and  delineate  research 

opportunities  which  we  view  as  promising. 

Briefly,  our  major  conclusions  concerning  current 

transportation  ADP  and  system  applications  are: 


1.  There  is  an  alarmingly  low  level  of  actual  implementation 
of  information  systems,  especially  at  MSC,  in  spite  of 
the  existence  of  competent  macro  system  designs  for  many 
operational  systems. 

2.  The  horizontal  and  vertical  interfaces  between 

organizations  and  within  planning  processes  is  poor, 
leading  to  time-consuming,  error-prone  human  intervention 
and  poor  responsiveness  in  both  planning  and  execution  of 
several  key  activities,  including  strategic  mobilization 
plann i ng. 

3.  A  decision  orientation  to  provide  guidance  for  system 
design  activities  is  not  apparent  in  the  current  system. 
This  results  in  part  from  uncertainties  resulting  from 
the  current  debate  on  merger  of  MSC  and  MTMC . 

4.  There  is  a  lack  of  focus  in  current  systems  on  defining 
the  scope  of  (de) centralization  of  design,  development 
and  implementation  of  transportation  systems.  The 
present  technology  is  oriented  towards  transactions 
processing,  not  (model-based)  decision  and  command 
support. 


Based  on  these  conclusions,  we  recommend  future  research  and 
development  in  three  areas:  system  design,  performance 
evaluation,  and  model  development. 

System  Design:  An  immediate  priority  should  be  to  move  ahead 
with  the  design  and  implementation  of  operating  systems  at  MSC. 
Such  operating  systems  in  support  of  traffic  management  will  be 
needed  in  any  case  to  provide  a  foundation  for  communication  and 
data  systems  for  the  evolving  Joint  Deployment  System. 
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Performance  Evaluation:  A  major  effort  should  be  undertaken 
to  define  operational  performance  measures  and  associated 
management  control  systems  to  determine  how  well  the  defense 
logistics  system  is  capable  of  fulfilling  its  strategic  missions. 
Such  systems  would  be  designed  to  track  and  diagnose  effectiveness 
(e.g. ,  response-time)  and  efficiency  (e.g.,  resource)  problems  in 
traffic  management. 

Model  Development:  A  final  area  recommended  for  near-term 
research  is  model-based  support  of  Joint  Operations  Planning. 
Here  we  suggest  investigating  the  potential  use  of  recent  research 
results  on  industrial  job  shops  to  improve  the  present  unwieldy 
(and  probably  unreliable)  approach  to  Joint  Operations  Planning, 
what  is  needed  is  a  planning  approach  that  recognizes  that  the 
specific  scenarios  (and  data)  used  in  mobilization  planning  will 
never  materialize  in  practice  because  of  environmental 
contingencies  and  uncertainties.  Thus,  more  flexible  and 
responsive  planning  systems  are  required  than  those  that  appear  to 
be  either  available  or  planned  for  the  support  of  Joint  Deployment 
Activities. 
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1.  Introduction 


This  research  was  sponsored  by  the  Office  of  Naval  Research 
and  was  directed  at  understanding  and  improving  systems  design 
procedures  in  support  of  DoD  surface  transportation  and  traffic 
management.  The  objective  of  this  study  was  to  investigate  the 
use  and  potential  impact  of  state-of-the-art  information  systems 
technology  and  model-based  planning  procedures  in  support  of 
decision  making  for  defense  surface  transportation.  The  research 
investigators  were  initially  concerned  only  with  Military  Sealift 
Command  (MSC)  operations  and  its  interfaces  with  the  Military 
Traffic  Management  Command  (MTMC ) ,  but  we  quickly  learned  that 
defense  transportation  and  traffic  management  are  inseparable  from 
broader  issues  of  joint  deployment  and  strategic  mobility 
planning.  Our  study  has  therefore  also  considered  these  more 
strategic  issues  as  they  relate  to  surface  transportation  and 
traffic  management. 

Our  research  .specifically  excluded  any  consideration  of  the 
merits  of  proposals  to  merge  MSC  and  MTMC  into  a  unified  command 
structure.  This  question  has  been  studied  in  a  separate  research 
project  [Keech,  1983]  .  However,  two  issues  related  to  the  merger 
question  are  discussed  in  this  report.  First,  we  discuss 
guidelines  for  determining  which  system  design  and  development 
activities  should  be  (de) centralized  to  operating  and  area 
commanders  and  which  require  more  centralized  coordination  and 
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planning.  Second,  we  discuss  the  interaction  between  the 
definition  of  organizational  boundaries  among  TOA's  and  the  choice 
of  information  technology  for  decision  support  in  these  agencies. 
In  particular,  at  the  operational  level  of  traffic  management,  we 
find  that  the  definition  of  organizational  boundaries  is  less 
important  than  the  definition  of  compatible  data  transfer  and 
control  procedures. 

This  study  was  quite  limited  in  scope  and  was  directed  at 
providing  conceptual  foundations  for  follow-on  research  and  design 
activities.  The  procedure  followed  was  to  interview  knowledgeable 
parties  at  MSC,  MTMC,  JCS,  and  the  Department  of  the  Navy.  On  the 
basis  of  these  interviews  and  extensive  documentation  provided  by 
our  respondents  (see  references  for  a  partial  listing  of  source 
materials),  we  formulated  a  macro  descriptive  model  of  surface 
transportation  activities  and  associated  planning  and  management 
systems.  This  led  to  the  development  of  a  decision-oriented 
approach  to  macro  design  and  to  the  identification  of  research 
opportunities  for  more  effectively  supporting  decision  making  in 
surface  transportation  and  traffic  management.  The  results  of 
this  study  are  summarized  briefly  below. 

In  Section  2,  we  describe  surface  transportation  activities 
and  supporting  management  systems  through  a  horizontal  view  (the 
logistics  supply  chain  and  its  associated  agencies)  and  a  vertical 
view  (the  strategic,  tactical,  and  operational  decision  processes 
for  planning  and  control).  In  Section  3,  we  consider  the 
operational  level  in  more  detail  and  describe  basic  processes  and 
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systems  associated  with  cargo  traffic  management.  This  provides  a 
perspective  on  the  problems  of  horizontal  data  and  system 
integration  across  the  several  agencies  and  processes  supporting 
cargo  traffic  management.  In  Section  4,  we  discuss  design  and 
implementation  issues;  the  key  issue  is  the  degree  of 
(de) centralization  of  control/responsibility  for  design, 
development,  and  data  specification  within  and  among  agencies  in 
the  transportation  and  deployment  community.  In  Section  5,  we 
summarize  several  pressing  problems  with  the  current  state  of 
defense  transportation  systems  and  delineate  research 
opportunities  which  we  view  as  promising. 


2 .  A  Macro  Model  of  Defense  Transportation 

The  focus  of  this  research  is  the  design  of  decision-oriented 
systems  for  defense  transportation.  The  starting  point  for  this 
analysis  is  a  descriptive  model  of  defense  transportation.  The 
model  presented  here  is  based  on  one  developed  by  the  Office  of 
the  Chief  of  Naval  Operations,  Logistics  Plan  Division  (OP-40),  as 
elaborated  by  RAdm  Richard  Avritt  and  his  staff.  This  model  is 
oriented  toward  understanding  three  interacting  elements: 

Decisions:  What  are  the  key  decisions  involved  in 
transporting  cargo,  passengers,  and  POL  in  support  of  defense 
organizations  under  various  scenarios  (specific  to  war,  peace,  and 
theatre  of  operations)? 
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Organizations;  Which  organizations  and  command  centers  are 
responsible  for  making  decisions  and  for  designing  and  maintaining 
systems  in  support  of  these  decisions? 

Systems;  What  data,  models,  processing  routines,  and 
information  technology  will  be  used  to  implement  specific 
decision-support  functions? 

Figure  1  presents  an  aggregate  picture  of  these  three 
interacting  elements.  The  driving  element  is  the  set  of  decisions 
and  scenarios  underlying  the  defense  transportation  system.  In 
the  simplest  terms,  this  is  the  defense  transportation  mission 
statement:  effectively  fulfilling  logistics  requirements  for 
planning  and  execution  of  supply  and  resupply  requests  under 
various  pre-planned  scenarios  and  operational  conditions.  The 
decisions  and  planning  and  control  processes  associated  with  this 
mission  may  be  viewed  at  several  different  levels.  At  the 
strategic  level,  capacity  (e.g.,  size,  control,  and  composition  of 
rail  and  shipping  fleets),  readiness,  and  responsiveness 
characteristics  of  the  system  are  chosen  and  evaluated  and  overall 
control  is  exercised.  At  the  tactical  level,  resources  (such  as 
ships,  personnel,  and  terminal  facilities)  are  positioned  and 
managed.  At  the  operational  level,  demands  for  shipments  are 
entered  and  serviced. 

The  second  and  third  elements  depicted  in  Figure  1  are  the 
nature  of  goods  transported  (cargo,  POL,  and  passengers)  and  the 
organizations  involved  operationally  in  generating  demands  on  the 
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defense  transportation  system  and  in  fulfilling  these.  A  more 
detailed  view  of  these  two  interacting  elements  is  presented  in 
Figure  2.  There  we  show  the  end  users,  the  CINCs  and  the  Joint 
Chiefs  of  Staff  (JCS) ,  initiating  preplanned  and  spot  requests  for 
transportation  services,  which  are  processed  and  encoded  for 
execution  by  the  supply  organizations  (depots,  vendors,  force 
deployment  commands)  and  mode  operators  (MAC ,  MSC,  and  MTMC) . 
These  transportation  requests  are  then  carried  out  through  joint 
activities  by  the  supply  organizations  and  mode  operators,  and 
their  progress  and  successful  completion  is  monitored. 

Several  different  perspectives  are  useful  in  viewing  decision 
support  activities  in  this  environment.  At  the  most  basic  level, 
the  traffic  management  function  must  be  supported  in  providing  for 
the  movement  of  goods  and  personnel  and  associated  transactions 
processing  within  the  logistics  chain  of  supply-mode  operator-end 
user.  A  second  perspective  is  the  command  level  (strategic, 
tactical,  and  operational)  associated  with  planning  and  control  of 
the  transportation  system.  The  third  perspective  in  systems 
design  is  the  definition  of  organizational  boundaries  for  agencies 
and  commands  responsible  for  various  activities  in  the  system. 

These  three  perspectives  can  generate  a  large  number  of 
alternative  system  designs,  depending  on  the  manner  in  which  they 
are  mutually  defined  and  coordinated.  A  concrete  recommendation 
on  the  proper  integrated  perspective  for  systems  design  and 
control  would  require  a  much  more  detailed  study  than  our  limited 
research  project  allowed.  A  first  step  in  this  regard  is  to 
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understand  the  different  nature  of  activities  and  responsible 
organizations  involved  in  defense  transportation.  The  following 
classification  of  these  activities  and  supporting  systems  is 
useful  for  this  purpose. 

Corporate:  Personnel,  financial,  and  administrative  systems 
serving  the  parent  services  involved  (Army,  Navy,  MARAD,  etc.). 

Transportation:  Systems  (e.g.,  JOPS,  SEACOP,  CALSTAT)  in 
support  of  strategic,  tactical  and  operational  planning  and 
control  of  the  overall  transportation  system  per  se,  including 
booking,  routing  and  scheduling  systems. 

Mode:  Systems  specific  to  the  operational  control  of 
alternative  transportation  modes/handling  facilities  (e.g.,  SMIS, 
Rail  and  Ship  Loading  Systems,  Terminal  Management  Systems). 


A  summary  of  the  interactions  between  the  above  three  types 
of  systems  and  the  decision  processes  they  support  is  presented  in 
Figure  3,  where  we  depict  the  interaction  between  command  levels, 
organizational  responsibilities,  and  physical  and  data  flows 
inherent  in  the  present  system.  This  Figure  illustrates  several 
key  issues  for  systems  design  and  implementation. 


Decision-Oriented  Systems:  I n 
information  systems  and  models  are 

decision-making,  execution  and  control, 
issue  in  any  systems  design  perspective 
decision. 


the  final  analysis, 
implemented  to  support 

Thus,  the  fundamental 
is  the  delineation  of  the 


planning,  and  physical  processes  of  interest.  This 


may 
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seem  trite,  but  it  is  not.  For  example,  is  the  purpose  of  JOPS 
and  OPLANs  to  allow  the  JCS  and  JDA  to  decide  and  pre-plan  the 
aggregate  feasibility  of  force  movement  and  resupply  schedules 
under  given  scenarios  (with  detailed  feasibility  evaluation  under 
the  control  of  responsible  TOAs)?  Or  is  it  to  determine  force 


movement  and  resupply 

schedules 

in  detail? 

If 

the 

first 

(aggregate  feasibility) 

view  is 

maintained, 

then 

the 

set  of 

information  which  would  be  made  available  to  the  JDA  would  be  only 
that  required  for  them  to  make  aggregate  capacity  and  force 
movement  decisions.  If  the  second  (detailed)  view  is  maintained, 
then  much  more  detailed  information  would  have  to  be  accessible  to 
the  JDA  to  generate  the  desired  output.  The  consequences  for 
database  management,  communications,  and  systems  support  would  be 
rather  different  for  each  of  these  views. 

Communications  and  System  I  nter faces — Fi  Iters:  ’’’he  issue 
just  raised  points  to  the  critical  importance  of  designing 
communications  and  system  interfaces  with  a  view  towards  what 
information  is  needed  to  support  decision  processes  at  the  proper 
level.  Continuing  our  example  of  generating  OPLANs,  a  major 
problem  with  the  present  process  is  in  obtaining  data  in  a  format 
which  is  readily  usable  in  lower  level  evaluation  processes.  For 
example,  MSC  needs  its  data  on  deployment  and  resupply  schedules 
to  be  translated  into  a  format  compatible  with  ship  loading  (e.g., 
data  indexed  by  source,  destination,  volume,  weight,  cargo 
classification,  and  special  handling  and  shipping  requirements). 
MTMC  uses  other  transportation  modes  and  must  interpret  OPLAN  data 


Page  8 


relative  to  these  modes.  The  JDA  is  concerned  with  such 
transportation-specific  data  only  to  the  extent  that  it  affects 
timing  and  feasibility  issues  of  force  movements  and  resupply 
requirements.  At  present,  large  efforts,  involving  thousands  of 
hours  of  manual  and  imperfect  interventions,  are  involved  in 
translating  the  requirements  of  one  agency  to  those  of  another. 
Automating  this  process  will  require  a  delineation  of  compatible 
data  formats  and  translation  systems  to  support  the  processes 
specific  to  each  agency /organization. 


Local/Global  Systems:  The  third  issue  of  importance  arising 
from  Figure  3  is  the  distinction  between  local  and  global  systems 
and  data.  One  of  the  most  important  lessons  we  have  learned  in 
information  and  decision  support  systems  over  the  past  two  decades 
is  the  difficulty  of  designing,  implementing  and  maintaining 
large,  complex  centralized  systems.  Efforts  to  design  totally 
integrated  data  bases  and  systems  for  large  endeavors  have  had  a 
very  low  success  rate  and  are  a  thing  of  the  past.  The  present 
philosophy  favors  distributed  data  acquisition,  maintainance  and 
processing.  This  permits  an  evolutionary  approach  to  designing 
and  implementing  smaller  pieces  of  the  overall  system.  It  also 
presents  us  with  a  set  of  major  design  choices:  which  decisions 
and  planning  processes  will  be  under  the  local  control  of  specific 
agencies  and  which  will  be  designed  to  encompass  several  agencies. 


Locally  controlled 
design  standardization 
duplication  of  effort. 


systems  may,  of  course,  involve  some 
and  joint  prototype  development  to  avoid 
In  the  case  of  global  or  inter-agency 
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systems,  considerably  larger  amount  of  resources  must  be  devoted 
to  the  initial  and  on-going  coordination  problems  of  making 
systems  used  and  useful  to  all  agencies  involved.  In  the  absence 
of  such  coordination,  systems  will  tend  to  fragment  to  fit  only 
local  user  needs.  The  on-going  debate  about  MSC  and  MTMC  planning 
procedures  is  a  good  case  in  point.  Each  currently  treats  the 
other  as  a  "black  box"  in  its  own  planning  processes  for  cargo 
movement  and  handling.  Efforts  to  totally  integrate  their  joint 
system  development  activities  would  be  very  complicated  to 
implement  (given  the  diverse  nature  of  the  transportation  modes 
each  is  responsible  for).  Yet  some  joint  planning  and  control 
systems  and  databases  must  be  established  to  improve  the 
efficiency  and  effectiveness  of  their  overall  function.  (The  same 
local/global  tradeoffs  exist  in  coordinating  the  development  of 
systems  employed  by  area  commanders  within  each  TOA.)  Delineating 
which  systems  will  be  jointly  planned  and  maintained,  and  which 
locally,  is  the  key  issue  here. 

Using  the  above  systems/activities  classification  (corporate, 
transportation,  mode),  one  would  expect  as  a  general  guideline 
that  corporate  systems  would  be  designed  and  maintained  by  parent 
services,  mode  systems  would  be  local  to  mode  operators,  and 
transportation  systems  would  be  centrally  (i.e.,  globally) 
designed  (though  very  likely  implemented  and  maintained  locally). 
There  are  many  interactions  between  these  system  types,  however, 
so  more  detailed  analysis  is  clearly  necessary. 
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In  order  to  explore  the  above  issues  in  a  more  concrete 
fashion,  we  now  consider  the  operational  level  of  planning  and 
systems  development  (the  cargo  traffic  management  function)  in 
more  detail. 

3 .  I ssues  in  Systems  Design  for  Cargo  Traf f i c  Management 

In  this  section  we  examine  the  operational  level  of  cargo 
traffic  management  in  order  to  illustrate  the  interaction  between 
management  activities  and  information  system  elements  in 
developing  a  management  support  system.  It  is  possible  to  view 
the  system  from  at  least  three  different  perspectives:  physical 
flows,  information  flows,  and  organizational  responsibilities.  It 
is  difficult  to  capture  all  of  these  perspectives  at  once,  so  a 
good  starting  place  is  to  consider  the  physical  reality  —  namely, 
the  flow  of  goods.  Figure  4  shows  this  process  for  containerized 
cargo  moved  from  CONUS  to  Europe.  The  top  row  of  boxes  depicts 
stages  of  movement  for  containerized  cargo,  and  the  bottom  row 
indicates  the  flow  of  empty  (or  partially  loaded)  containers  in 
the  opposite  direction  since  there  are  also  significant  management 
problems  associated  with  containers.  This  figure  would  have  to  be 
modified  slightly  to  accomodate  other  types  of  cargo  —  e.g., 
breakbulk  or  POL  --  mainly  by  eliminating  the  return  path  for 
containers. 

The  performance  of  this  system  is  measured  in  terms  of 
effectiveness  and  economy  in  carrying  out  its  mission.  Some 
specific  criteria  are: 
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Effect rveness: 

-  Meets  requirements  for  throughput 

-  Meets  due  dates 

-  Accomodates  priorities 


Economy: 


-  Fees  to  carriers 


-  Utilization  of  resources  —  e.g. ,  number  of 

railcars,  containers,  personnel 

-  Inventory  costs  for  cargo  in  the  pipeline 

-  Sloppiness  costs  —  e.g.,  detention,  overtime. 


ships. 


excess 


warehousing 

-  Information  processing  —  e.g.,  paper  handling,  redundant 
data  entry,  status  monitoring 


In  the  chain  of  management  systems  employed  by  TOA's  to 
connect  the  supplier  of  material  and  the  end  user,  the  activities 
of  Booking,  Routing,  and  Scheduling  are  generally  viewed  as  the 
key  processes.  Figure  5  indicates  a  useful  way  of  thinking  about 
these  processes  in  two  ways.  First,  we  have  labelled  as 
"Management  Activities"  four  types  of  functions  that  must  be 
accomplished  in  doing  the  job.  At  the  bottom  of  the  Figure, 
labelled  "Information  Systems  Elements",  are  found  types  of 
information  systems  and  data  processing  operations  that  may  be 
used  in  support  of  these  functions  in  building  management  systems. 
More  specifically,  we  define  the  four  management  functions  as 
f o 1  lows: 


t 
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1.  Decisions  are  the  choices  to  be  made  in  allocating 
transportation  resources  to  the  tasks  that  must  be 
accomplished,  including  determination  of  the  when,  where, 
and  how  of  traffic  movement.  Explicit  identification  of 
these  decisions  is  critical  since  system  performance 
depends  on  supporting  these  decisions.  The  alternative 
focus  on  functions  or  processes  leads  to  misdirection  in 
system  design  and  lower  performance  of  the  resulting 
system  design. 

2.  Monitoring  and  control  involves  gathering  status 
information  and  verifying  that  planned  events  take  place. 
This  closes  the  loop  on  the  decision  making  steps  to 
ensure  that  decisions  are  successfully  implemented  and 
that  assumptions  have  not  been  violated. 

3.  Evaluation  relates  decisions  to  information  gathered  from 
monitoring  and  control  activities  in  order  to  measure 
performance  against  the  criteria  mentioned  above. 

4 .  Documentation,  requests ,  and  notif ication  are  the 
vehicles  for  communicating  information  about  decisions, 
anticipated  events,  and  status. 

Table  1  provides  further  examples  from  each  of  these  categories. 

In  order  to  remain  unconstrained  in  thinking  about  the 
management  of  cargo  movement  and  the  systems  to  support  that 
function,  we  are  purposely  not  elaborating  on  organizational 
responsibilities  for  specific  decisions  and  tasks  or  the  details 
of  "paper  handling". 

Each  of  the  typical  decisions  listed  in  Table  1  may  be  made 
sequentially  and  in  isolation,  and  in  practice,  often  is. 
However,  these  decisions  actually  interact;  for  example: 


1.  Booking  and  scheduling:  the  choice  of  a  carrier  is 

dependent  on  its  schedule,  but  the  schedule  may  be 
determined  by  the  location  and  volume  of  cargo  available. 

2.  Booking  and  routing:  the  choice  of  a  carrier  implies  a 

date  by  which  a  container  must  reach  a  terminal  and  hence 

a  choice  of  routes;  choosing  the  route  before  the 

booking  affects  container  utilization,  the  POD,  and  hence 
the  choice  of  a  carrier  and  POE. 


L 
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1 

Hence,  a  proper  system  perspective  must  recognize  and  accomodate 
these  circular,  interacting  decision  activities. 

In  order  to  illustrate  the  design  problem,  we  will  explore  a 
scheduling  problem  in  more  detail.  Consider  the  problem  of 

scheduling  a  ship  to  call  at  a  port.  In  developing  a  methodology 
for  solving  this  problem,  there  are  many  options  in  terms  of  what 
data  are  to  be  considered  and  which  other  previously  made 
decisions  are  to  be  taken  as  constraints,  ignored,  or  possibly 
changed.  For  example,  the  system  could  (1)  attempt  to  have  a  ship 
arrive  at  a  given  port  once  every  week,  regardless  of  the  amount 
'  of  available  cargo;  (2)  alternatively,  one  could  attempt  to 

achieve  better  responsiveness  and  higher  utilization  by  planning 
ship  arrivals  in  accordance  with  projected  levels  of  cargo 
availability;  (3)  a  more  ambitious  system  might  attempt  to 
simultaneously  schedule  the  arrival  of  cargo  and  ships  to  the  POE. 
Still  ignoring  traditional  assignments  of  responsibility  for 
decision  making,  definition  of  the  scope  of  this  particular 
scheduling  problem  involves  tradeoffs  along  several  dimensions; 

1.  The  definition  of  meaningful,  quantifiable  tradeoffs 
among  alternative  performance  measures. 

2.  Inclusion  of  detailed  status  information  and  forecasts. 

3.  Accomodation  of  uncertainties  arising  from  unpredicted 
events. 

4.  The  number  of  alternative  solutions  explored  and  hence 
the  level  of  payoff  achieved. 


J 
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5.  The  cost  of  solving  the  defined  problem  relative  to  the 
expected  benefits. 

Referring  back  to  the  three  scheduling  approaches  mentioned 
above,  one  might  observe  that  Option  1  is  taken  by  commercial 
carriers  using  aggregate  data  since  their  influence  on  demand  is 
limited.  The  current  defense  logistics  system  seems  to  use  an 
approach  similar  to  Option  2  combined  with  an  optimizing 
methodology.  Option  3  represents  an  expansion  of  the  scope  of  the 
problem,  but  using  more  highly  aggregated  data  describing  more  of 
the  world  and  heuristic  (as  opposed  to  mathematical  optimization) 
techniques.  Although  it  represents  a  more  difficult  problem  than 
either  Options  1  or  2  and  may  require  the  realignment  of 
organizational  boundaries.  Option  3  has  the  potential  for  a  higher 
payoff  than  either  of  the  other  options. 

The  information  system  elements  in  Figure  5  have  the 
following  interpretations: 

1.  Transaction  processing  involves  capturing,  entering, 
verifying,  and  storing  data  related  to  decisions  and 
events. 

2.  Communication  means  transmitting  information  between 
users  either  on  a  routine  basis  or  upon  request. 

3.  Inquiry  involves  extracting,  filtering,  aggregating,  and 
displaying  information  from  the  organizational  database 
in  support  of  the  management  activities. 

4.  Mode  1  usage  is  employing  procedures  to  support  and 
facilitate  decision  making  once  the  necessary  information 
has  been  assembled  through  inquiry  processes. 


The  development  of  these  information  system  elements 


is  highly 
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dependent  on  the  availability  of  suitable  computer  technology; 
there  are  also  many  alternative  approaches  to  satisfying 
management’s  information  processing  requirements. 

Ultimately,  the  determination  of  the  scope  of  a  particular 
problem,  such  as  scheduling,  implies  a  range  of  specific 
management  activities  and  responsibilities  —  e.g.  ,  types  of 
decisions,  monitoring  activities  —  and  specific  information 
access  and  processing  requirements  that  must  be  supported  by  the 
various  information  system  elements.  We  recognize  that  these 
processing  requirements  may  be  difficult  or  impossible  to  satisfy 
with  current  technology  or  within  current  organizational 
constraints.  However,  three  observations  can  be  made.  First, 
this  problem  may  be  approached  by  iterating  between  the  design 
processes  for  management  activities  and  information  system 
elements  until  the  conflicts  are  resolved.  The  critical  point  is 
that  this  iteration  must  begin  with  the  consideration  of 
management  activities  rather  than  the  available  or  planned 
information  systems.  Second,  although  this  design  process  is  a 
difficult  one  to  follow,  it  provides  the  highest  potential  for 
developing  a  satisfactory  system  design.  Third,  even  once  an 
appropriate  design  is  developed,  the  remaining  task  of  building 
the  system  may  still  be  a  very  difficult  one.  Section  4  discusses 
a  number  of  issues  and  considerations  in  building  such  large  and 
complex  systems  and  suggests  an  approach  that  employs 


state-of-the-art  technology  to  simplify  this  problem 
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To  the  extent  that  the  scope  of  a  management  activity  expands 
to  include  multiple  parts  of  the  physical  system,  serious  problems 
of  system  integration  and  horizontal  information  flow  among 
organizations  may  arise.  For  example,  if  a  particular  decision 
requires  a  model  of  wide  ranging  scope,  many  information  system 
elements  are  affected: 


1.  The  inquiry  component  must  accomodate  more  diverse 
requests  involving  a  wider  range  of  data. 

2.  The  communication  system  must  provide  access  to 
information  from  more  organizations'  databases. 

3.  The  transaction  processing  systems  must  capture  and  store 
new  varieties  of  data. 


The  resulting  issues  of  compatibility  and  interface  are  difficult 
ones  that  must  be  addressed  in  both  the  systems  design  process  and 
the  way  in  which  system  design  responsibilities  are  allocated 
among  organizations. 

4 .  ADP  Activities  in  ^SC:  Observat ions,  Concerns , 
and  Recommendations 

The  first  and  most  obvious  observation  regarding  ADP 
activities  at  MSC  is  that  there  are  many  systems  involved,  either 
in  use  (e.g.,  SEACOWIS,  SEACOP)  or  planned  (e.a.,  SEASTRAT,  CMSS, 
SID).  This  situation  implies  potentially  large  manpower  and 
resource  commitments  to  the  development  and  long-term  maintenance 
of  these  systems,  as  well  as  a  long  lead  time  for  implementat 1  on. 
For  instance,  SEACOMIS  alone  consists  of  hundreds  of  programs  and 
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apparently  still  does  not  satisfy  all  the  needs  identified  in  the 
corresponding  areas  of  the  Command  Information  Flow  Matrix 
developed  using  the  Business  Systems  Planning  methodology.  While 
the  number  and  complexity  of  such  systems  may  be  consistent  with 
MSC's  mission,  a  master  Information  System  plan  must  directly 
address  the  potential  problems  with  lead  times  and  costs  resulting 
from  the  use  of  conventional  systems  development  methodologies. 

Currently,  systems  are  scattered  over  many  processing  sites 
(e.g.,  CNO  WWMCCS  H6060,  mtmc's  H6060,  Navy  Manpower  Center,  David 
Taylor  R&D  Center)  and  types  of  operating  systems  and  hardware 
with  only  limited  opportunity  for  automated  interfacing,  let  alone 
integrated  information  access.  Since  MSC  does  not  operate  its  own 
DP  installation,  it  has  only  limited  control  over  processing 
priorities,  thereby  making  response  times  long  and  unpredictable 
and  decreasing  the  perceived  reliability  and  usefulness  of 
computer-based  systems.  In  particular,  this  type  of  processing 
environment  is  incompatible  with  the  support  of  activities  such  as 
time  sensitive  execution  planning  in  the  event  of  a  crisis. 

Limited  access  to  secure  lines  and  reliance  on  low  speed 
communication  links  suggest  that  timely  communication  could  not  be 
achieved  in  an  emergency.  Even  in  peacetime  operation,  these 
facilities  foster  a  complete  decentralization  of  processing  and 
information  (including  the  severing  of  all  automated  ties),  rather 
than  an  intelligent  distribution  of  computing  resources  and  the 
sharing  of  information. 
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Substantial  effort  and  time  has  already  been  devoted  to  the 
initial  System  Decision  Paper  (SDP)  outlining  the  overall  design 
for  an  Integrated  Management  Information  System  (IMIS)  for  MSC. 
Although  many  key  ideas  and  standards  —  such  as  hierarchical 
databases,  the  Open  System  Interface  standard,  and  local  area 
networks  —  have  been  identified,  many  of  these  ideas  are  still  in 
R&D  or  at  early  stages  of  deployment.  Hence,  the  underlying 
technologies  of  IMIS  are  potentially  risky  and  may  lead  to  delays 
in  implementation.  In  addition,  the  past  year  or  more  of  overall 
study  and  design  has  not  provided  a  detailed  analysis  of  any  piece 
of  the  system.  At  the  rate  at  which  system  needs  generally  evolve 
(while  the  complexity  of  requirements  increases),  the  system 
specification  may  be  outdated  by  the  time  SDP  II  is  completed,  not 
even  considering  unforeseen  delays. 

MSC  has  employed  a  top-down  design  approach  to  define  the 
functional  requirements  and  overall  design  guidelines  for  large, 
integrated  systems  such  as  IMIS.  A  major  bottleneck  in  this 
process  has  been  a  very  limited  central  staff  of  (currently  three) 
system  analysts.  The  Command  is  now  moving  to  implement  a 
strategy  of  centralized  design  coordination  with:  (i)  delegation 
of  specific  design  authority  to  area  commanders  and  (ii)  provision 
of  guidance  and  guidelines  by  a  central  staff.  However,  a  major 
constraint  may  still  be  the  limited  central  resources  for 
coordination  and  guidance. 
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By  contrast. 

the 

systems 

at 

mtmc  are 

largely 

"user-motivated". 

where 

the  user 

i  s 

defined  as  a 

specific 

functional  manager.  In  addition  to  requesting  system  development, 
the  user  is  responsible  for  preparing  the  Mission  Element  Needs 
Statement  (MENS),  the  functional  description  (FD) ,  and  the  overall 
data  requirements  (RD) ,  although  the  IS  staff  may  be  called  upon 
to  assist  in  this  process.  The  success  of  this  approach  is  at 
least  partially  due  to  the  sophistication  of  MTMC's  user  community 
that  derives  from  ten  years  of  experience  with  computer-based 
systems.  Once  the  initial  functional  requirements  are  determined, 
the  IS  staff  assumes  responsibility  for  system  design  and 
development  which  may  be  done  either  in-house  or  under  contract, 
depending  on  resource  availability.  In  general,  field  level 
systems  are  built  in  the  field,  while  systems  for  headquarters  are 
developed  at  headquarters;  systems  to  be  shared  among  several 
field  commands  are  developed  at  a  designated  site,  taking  into 
consideration  other  users'  needs,  and  then  propogated  to  other 
locations  when  completed.  While  MTMC  has  a  staff  of  over  100 
programmer-analysts  to  draw  upon,  their  effectiveness  is 
multiplied  by  concentrating  their  efforts  on  system  design  and 
development  since  the  user  does  most  of  the  initial  requirements 
and  functional  analysis. 
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Concerns  in  Designing  an  ADP  Systems  for  MSC 


At  least  four  major  areas  of  concern  must  be  addressed  in 
studying  the  overall  design  problem  for  MSC.  First,  MSC  is  part 
of  an  overall  supply  and  demand  process  which  requires  many 
external  interfaces.  This  interface  problem  is  complicated  by  the 
different  levels  of  interaction  both  in  peacetime  and  war/crisis 
situations: 


1.  The  Deliberate  Planning  (strategic/  peacetime)  activity 
involves  either  actual  or  potential  interfaces  with  JCS, 
JOA,  MAC,  MTMC ,  CINCS,  and  the  Services. 

2.  Time  Sensitive  Execution  Planning  during  a  crisis  (either 
an  exercise  or  real  world)  may  require  interface  with 
these  same  agencies,  along  with  MARAD,  in  order  to 
resolve  movement  requirements,  timetables,  and  potential 
constraints. 

3.  Both  Deployment  Execution  and  peacetime  operational 
activities  may  require  the  exchange  of  information  with 
the  Services,  DLA ,  DFSC,  MTMC,  NOSIC,  Area  Commands,  the 
Coast  Guard,  MARAD,  shipyards,  ship  operators,  and 
carriers. 


As  a  result,  the  flow  of  information  is  potentially  complex, 
non-standard,  and  difficult  to  manage;  currently  it  involves 
substantial  manual  intervention  and  translation  or  is 
non-existent. 


The  internal  activities  of  MSC  can  also  be  decomposed  by 
functional  area  —  such  as  accounting/finance,  engineering, 
medical,  supply,  contracting,  personnel,  and  fleet  operations. 
Each  area  further  subdivides  into  numerous  planning,  control,  and 
operational  activities  which  may  be  further  complicated  by 
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geographical  dispersion;  the  flow  of  information  among  these 
processes  has  already  been  documented  as  part  of  the  Business 
Systems  Planning  study.  While  external  interface  standards  and 
contents  are  either  dictated  by  other  agencies  or  presently 
undefined,  MSC  has  complete  control  over  the  internal  interfaces 
among  its  own  operating  units;  hence,  there  is  an  opportunity  to 
redistribute  information  among  various  storage  sites  while 
redesigning  the  flow  of  information  within  MSC.  In  fact, 
standardization  of  processing  methods  and  database  contents  among 
the  different  area  commands  would  reduce  development  and 
maintenance  costs  and  facilitate  the  interchange  of  information 
for  planning  and  control  purposes. 

At  least  some  portion  of  the  MSC  database  is  classified 
i nf orma t i on,  and  in  the  event  of  a  crisis,  additional  information 
--  such  as  ship  location  and  readiness  —  may  become  so.  Any 
overall  system  design  must  facilitate  this  transition  by  either 
providing  secure,  controlled  access  during  peacetime  or  permitting 
the  swapping  of  processing  tasks  and  communication  channels  to 
secure  sites  in  the  event  of  a  crisis. 

As  one  might  expect,  the  different  MSC  activities  exhibit  a 
wide  variation  in  priorities,  response  time  requirements,  volume 
of  information,  frequency  of  occurence,  and  locality  of  data 
reference.  In  particular,  further  localization  of  data  reference 
can  be  achieved  by  wider  use  of  aggregate  information  in  higher 
level  planning  and  control  activities.  In  any  case,  an 
appropriate  MIS  desion  must  provide  sufficient  capacity  and 
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flexibility  to  make  appropriate  tradeoffs  in  scheduling  the 
processing  load,  regardless  of  the  mix  of  MSC  activities  or  the 
crisis  level. 

The  general  implication  of  these  four  issues  is  that  the 
design  of  a  fully  integrated  MIS  is  likely  to  be  a  difficult, 
time-consuming  task  requiring  extensive  resources  and  leading  to 
delays  in  development  if  conventional  methodologies  are  employed. 
Furthermore,  the  commitment  of  additional  resources  beyond  the 
basic  design  team  is  as  likely  to  slow  down  the  development 
process,  as  accelerate  it. 

Recommendations 

This  section  provides  four  general  recommendations  regarding 
the  design  philosophy  and  methodology  used  in  developing  ADP 
systems  for  MSC: 

1.  As  mentioned  earlier,  the  designer  should  use  the 
decision  making  process  as  a  basis  for  deriving 
information  needs,  rather  than  simply  trying  to  include 
information  to  cover  all  possible  contingencies,  in  the 
design  of  both  managerial  reports  and  the  supporting 
database. 

2.  The  design  should  probably  sacrifice  generality  —  the 
ability  to  perform  many  different  tasks  or  variations  — 
in  order  to  gain  flexibility  or  extensibility  —  the 
ability  to  quickly  and  easily  change  or  augment  existing 
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facilities.  A  "general"  design  typically  strives  to 
identify  and  accomodate  all  of  the  likely  information  and 
processing  requirements  that  exist  or  may  arise  in  the 
future.  As  a  result,  it  usually  involves  a  large 
expenditure  of  manpower  and  a  long  development  period. 
Py  concentrating  on  the  underlying  decision-making 
process  and  selected  near  and  long  term  requirements,  a 
more  modest  design  can  be  developed.  This  design  can 
then  be  implemented  in  a  modular,  extensible  fashion 
using  technologies  such  as  database  management  systems 
(DBMS )  so  that  the  overall  system  can  evolve  to 
accomodate  new  or  changing  requirements.  Two  additional 
benefits  of  this  approach  are  that:  (i)  the  system  is 

available  more  quickly  for  productive  activities  and 
(ii)  the  effectiveness  of  the  required  support  can  be 
measured  directly  through  use  of  the  system.  Failure  to 
recognize  and  exploit  this  tradeoff  between  generality 
and  flexibility  often  results  in  complex  designs  that  are 
risky  and  costly  to  implement. 

3.  The  ADP  design  should  strive  for  economies  of 

specialization  (i.e.,  avoid  the  diseconomies  associated 
with  providing  generalized  capabilities)  rather  than 
economies  of  scale.  This  strategy  favors  (a)  a 
distributed  network  of  processors  over  a  large. 


centralized  system  in  order  to  increase  the  reliability 
and  reduce  the  complexity  of  the  system;  and 
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(b)  aggregated  databases  to  facilitate  higher  level 
planning  and  control  activities  rather  than  global, 
real-time  access  to  all  data,  thereby  reducing  response 
time  and  communication  requirements  and  facilitating  the 
exploration  of  a  greater  variety  of  alternatives  during 
the  planning  process. 

4.  The  design  and  implementation  should  employ  fourth 
generation  development  tools,  such  as  DBMS,  nonprocedural 
languages,  and  ad  hoc  inquiry  languages,  to  (a)  increase 
programmer  productivity,  (b)  push  more  of  the  develpment, 
operational,  and  maintenance  responsibility  back  onto  the 
end-user;  and  (c)  facilitate  the  prototyping  of  early 
system  designs  to  provide  feedback  to  users,  rather  than 
iterating  on  paper  to  finalize  a  design. 

5 .  Assessment  of  Current  Status  and  P roposed  Research 

The  current  systems  for  supporting  defense  transportation  are 
flawed  in  several  important  ways  relative  to  the  ideal  perspective 
described  in  this  report.  Most  of  these  shortcomings  are 
generally  recognized,  but  it  would  be  appropriate  to  briefly  list 
these  from  our  own  perspective. 

Low  Level  of  ADP  Implementation;  A  critical  problem  at  this 
time  is  the  low  level  of  ADP  systems  implementation,  especially  at 
the  operational  level  (traffic  management)  at  MSC.  A  great  deal 
of  fairly  sophisticated  planning  has  been  done  at  both  MSC  and 
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MTMC,  but  merger  issues  have  delayed  both  detailed  design  and 
implementation.  Any  progress  in  improving  readiness  and 
responsiveness  of  defense  transportation  must  recognize  the 
critical  need  for  automating  key  traffic  management  functions  and 
their  data  and  organizational  interfaces.  The  first  step  in 
improving  the  situation  would  be  to  increase  the  number  of  ADP 
personnel  available  to  MSC  for  systems  analysis  and  development 
activities.  In  parallel,  a  high-level  planning  committee  should 
he  convened  at  the  earliest  juncture  to  sort  out  local  and  global 
design  and  implementation  responsibilities  and  to  recommend 
priorities  for  funding  these. 

Poor  0 rgani2ational  and  System  Interfaces:  A  related  problem 
is  the  transfer  of  data  and  results  from  existing  systems.  This 
relates  to  both  MSC-MTMC  tactical  repons ibi  1  i ties  as  well  as  to 
the  interface  of  strategic  mobilization  systems  (e.g.,  JOPS)  with 
mode  operators.  The  present  strategy  of  manual  tape  transfers  and 
adjustments  is  both  inefficient  and  potentially  disastrous  in  the 
event  of  wartime  responsiveness  conditions.  While  many  of  these 
inter-organizational  "filtering"  problems  cannot  be  resolved  until 
an  overall  system  design  perspective  is  adopted,  certain  key  areas 
can  and  should  be  dealt  with  immediately.  The  most  obvious  is 
strategic  mobilization  (JOPS  and  related  systems).  According  to 
staff  in  the  OJCS,  the  problem  of  stating  OP LAN  requirements  to 
the  TOAs  is  not  at  a  level  which  can  be  easily  translated  to 
mode-operator  planning  and  feasibility  evaluation.  Methods  for 
improving  the  JDA- (MAC-MSC-MTMC)  interfaces  need  to  be  given  high 


J 


Page  26 


priority.  These  would  include  data  compatibility,  communications, 
and  systems  interfaces,  and  their  potential  for  automation. 

Decision-Oriented  Systems  Design:  A  matter  of  some 
importance  in  determining  ADP  requirements  and  priorities  should 
be  the  nature  of  the  decisions  supported  with  ADP.  Adopting  this 
perspective,  as  suggested  in  the  above  analysis,  would  enable  a 
command-oriented  design  of  systems.  It  would  help  answer 
questions  like  "why  is  this  information  needed  at  this  level", 
"what  priority  should  be  attached  to  the  implementation  of  this 
system",  and  "what  efficiency  and  effectiveness  criteria  should  be 
applied  in  designing  this  system  for  this  activity"?  Such 
questions  as  these  are  not  readily  answered  for  many  of  the 
present  systems  (either  in  the  planning  stage  or  actually 
implemented) . 

Loca 1-G loba 1  I ssues:  A  final  matter  of  some  importance 
concerning  current  systems  is  their  lack  of  focus  on  the 
local-global  design,  development,  and  implementation  issues  which 
figure  so  centrally  in  state-of-the-art  ADP  and  decision  support 
systems.  The  present  technology  is  oriented  toward  transactions 
processing  with  a  heavy  emphasis  on  centralized  control  in  all 
transportation  functions  which  are  automated.  To  be  sure,  some 
progress  is  being  made  (e.g.,  in  MTMC's  local 
booking-offering-billing  systems)  towards  distributed  processing 
using  mini-computers,  but  there  appears  to  be  no  joint  coherent 
system  design  perspective  across  MSC  and  MTMC  concerning  which 
functions  are  local  (to  be  dealt  with  by  MSC  and  MTMC  separately) 
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and  which  are  global — and  why? 


This  leads  to 


myopic  behavior 

(e.g.,  sending  rail  shipments  to  ports  where  no  appropriate  ship 
is  available)  and,  worse  still,  a  time-consuming,  human-intensive 
response  to  enforced  global  coordination  exercises  like  the 
generation  of  OPLANs.  A  clear  philosophy  for  delineating 
local-global  system  definition  responsibilities  and  coordinating 
the  design  of  global  systems  is  a  most  important  item  for  the  near 
future. 

If  the  above  is  a  reasonable  picture  of  short-comings  in  the 
current  system,  the  following  seem  to  be  high  pay-off  areas  for 
research  and  development. 

System  Design;  We  have  spelled  out  a  macro  perspective  for 
understanding  and  improving  decision  making  and  planning  through 
decision-oriented  systems.  Several  research  and  development 
priorities  emerge  immediately  from  this  perspective.  The  most 
important  are  implicit  in  the  above  comments  on  the  shortcomings 
of  the  present  system.  First,  traffic  management  functions  are 
not  likely  to  change  rapidly  at  the  operational  level.  This 
suggests  an  immediate  priority  of  designing  operational  systems 
(especially  at  MSC  where  the  current  status  is  bleak)  to  realize 
the  benefits  which  such  systems  can  bring  in  the  short  and  medium 
run  and  to  provide  a  database  for  building  future  tactical  and 
strategic  systems.  Second,  the  interfaces  in  strategic 
mobilization  planning  between  JDA  and  mode  operators  should  be 
cleaned  up  as  quickly  as  possible,  with  an  eye  on  likely  future 
system  developments  (e.g.,  SEASTRAT)  within  MAC,  MSC,  and  MTMC , 
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but  also  in  the  short-run  interest  of  making  strategic 
mobilization  planning  more  responsive  in  its  current  form. 
Finally,  a  major  study  should  be  undertaken  to  flesh  out  a  macro 
design  for  integrated  (but  distributed)  transportation  planning 
and  execution.  The  ideas  of  this  report  may  be  useful  in 
describing  the  nature  and  goals  of  such  a  study. 

Performance  Evaluation;  System  design  efforts  are  supposed 
to  start  with  a  statement  of  the  objectives  of  the  design  effort 
in  question  and  performance  measures  for  evaluating  efficiency  and 
effectiveness  of  the  process  one  is  trying  to  improve.  A  major 
problem  with  many  logistics  systems,  both  private  and  public 
sector,  is  that  such  performance  measures  are  typically  not 
defined  in  an  operational  manner.  It  is  not  so  much  that  a 
general  understanding  of  transportation  efficiency  and 
effectiveness  is  lacking,  but  rather  that  no  on-going  management 
and  command  systems  are  implemented  to  control  it.  The  typical 
criteria  for  evaluating  transportation  systems  are  cost,  response 
time  (both  planning  and  execution),  controllability,  and  graceful 
degradation  (soft  failure).  For  example,  what  are  the 
response-time  requirements  for  generating  and  evaluating  OPLANs 
(to  some  level  of  detail)  and  how  well  are  these  met?  What  are 
the  response-time  requirements  for  resupply  of  various  priorities 
of  equipment  and  personnel  for  various  source-destination  pairs? 
How  are  these  priorities  defined  and  who  sets  and  controls  them? 
What  is  response  time  (an  average  time,  a  specified  fractile  of 
the  response-time  distribution,  an  average  across  various  classes 
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of  cargo,  POL,  etc.)?  As  recent  work  on  logistics  systems  in  the 
private  sector  has  shown,  even  though  such  performance  measures 
might  be  understood  in  aggregate,  translating  them  into 
operational  terms  and  designing  systems  to  track  them  is  a  complex 
task,  even  in  the  simple  case  of  a  manufacturing  organization  in  a 
peaceful  world.  Clearly,  the  environment  of  defense  logistics  is 
much  more  complicated  and  deserves  a  careful  study  of  performance 
evaluation  and  management  control  systems. 


Mode  1  Development  to  Support  Joint  Operations  Planning;  A 
final  area  of  importance  for  future  research  is  model-based 
support  of  joint  operations  planning.  As  we  understand  the 
current  planning  process,  the  objective  of  the  exercise  is  to 
develop  detailed  plans  down  to  actual  ship  schedules  (movement 
tables)  that  provide  the  essential  operating  details  for  specific 
scenarios.  In  a  real  contingency,  however,  only  a  very  short  time 
would  elapse  before  the  actual  situation  deviated  significantly 
from  the  anticipated  scenario,  and  thus  such  detailed  plans  would 
be  useless.  That  is,  the  current  approach  develops  plans  to 
satisfy  highly  uncertain  demands  as  though  there  were  no 
uncertainty,  and  does  this  planning  in  great  detail.  This  concept 
does  not  make  a  great  deal  of  sense,  and  therefore  research  based 
on  other  concepts  of  planning  would  be  very  worthwhile.  The 
principal  virtue  of  the  current  planning  mode  is  that  it  provides 
a  starting  point  for  the  mobilization  process.  In  addition,  the 
existence  of  a  feasible  plan  assures  that  the  system  can  respond 

at  least  in  some  situations  if,  in  fact,  a  feasible  plan  can  be 
worked  out. 
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What  is  needed  is  a  planning  approach  that  recognizes  that 
the  specific  scenarios  used  in  mobilization  planning  will  never 
materialize  in  practice  simply  because  the  detailed  requirements 
of  a  real  contingency  are  unpredictable.  An  analogous  situation 
arises  in  manufacturing  enterprises,  and  therefore,  planning  and 
control  methods  from  the  industrial  sector  could  serve  as  a  basis 
for  a  better  approach  to  mobilization  planning  in  the  military. 

The  analogous  situation  in  a  manufacturing  settinq  is  called 
an  "open  job  shop".  A  job  shop  is  a  set  of  facilities,  typically 
groups  (machine  centers)  of  equipment.  The  demands  placed  on  the 
facilities  are  "jobs"  or  "orders",  each  of  which  has  a  particular 
required,  possibly  unique,  routing  through  various  machine 
centers.  Moreover,  the  time  required  to  process  a  job  in  a 
machine  center  varies  from  job  to  job.  The  "open"  descriptor 
refers  to  the  fact  that  the  enterprise  accepts  orders  originating 
from  outside  the  firm,  and  thus,  the  firm  does  not  have  total 
control  of  the  demands  placed  upon  it.  To  draw  an  analogy  with 
military  logistics,  the  demands  for  movement  of  cargo,  people,  and 
POL  are  the  jobs,  while  the  rail  resources,  port  facilities,  and 
ships  of  various  kinds  are  the  machine  centers. 

The  goals  of  successful  management  in  a  job  shop  are  not  too 
different  from  those  in  a  transportation  system:  the  firm  is 
concerned  with  maximizing  throughput,  meeting  delivery  dates, 
minimizing  work  in  process  inventory  (jobs  in  the  system),  and 
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efficiently  utilizing  resources  (to  minimize  the  cost  of 
alternatives  such  as  overtime,  subcontracting,  or  turning  away 
business) . 

A  job  shop  requires  a  vast  number  of  decisions  to  keep  it  in 
operation,  varying  in  importance  from  what  products  should  be 
manufactured,  what  facilities  should  be  operated,  and  how  many 
workers  of  various  skills  are  required  each  month,  to  what  should 
be  the  routing  of  a  particular  order  and  what  job  should  be  done 
next  in  the  milling  machine  department.  Two  characteristics  of 
planning  in  this  environment  are  that  (1)  the  set  of  decisions  and 
data  requirements  are  much  too  extensive  and  complicated  to  make 
all  decisions  simultaneously  and  (2)  it  is  impossible  to  schedule 
the  detailed  movements  of  individual  jobs  very  far  in  advance  of 
the  time  when  the  movements  are  to  be  carried  out  simply  because 
there  is  no  way  to  predict  exactly  what  jobs  will  be  in  the  shop. 
Moreover,  there  are  many  random  perturbations  due  to  machine 
breakdown,  quality  problems,  material  shortages,  rush  orders,  and 
the  like. 

How  do  companies  cope  will  all  of  this?  The  most  successful 
firms  adopt  a  hierarchical  approach  whereby  they  make  the 
significant  long  term  decisions  with  aggregate  data.  As  they  move 
down  the  hierarchy  of  decisions,  the  decisions  become  more 
detailed  and  cover  shorter  time  spans.  As  explained  in  Buffa  and 
Miller  [1979]  or  Holstein  [1968] ,  a  typical  four-level  hierarchy 
of  decision  making  would  be: 
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(1)  Long  term  capacity  planning:  major  adjustments  of  capacity 
to  match  projected  requirements. 

(2)  Master  scheduling:  match  available  capacity  to  individual 
products  (typically,  projected  monthly  demands  over  6  to  18 
months)  and  major  orders.  Minor  capacity  adjustments  such  as 
those  involving  overtime  and  subcontract ing. 

(3)  Short-term  scheduling:  more  detailed  and  shorter  time 

horizon  than  master  scheduling  in  order  to  ensure  that 
delivery  commitments  can  be  met. 

(4)  Dispatching  and  shop  control:  immediate  (virtually 

real-time)  decisions  to  assign  specific  tasks  to  individual 
machines  and  workers. 

In  the  analogy  with  mobilization  planning,  it  seems  that  the 
current  method  is  to  try  to  do  steps  2,  3,  and  4  all  at  once,  even 
though  the  dispatching  decisions  must  be  made  all  over  again  when 
the  time  comes  to  put  the  plan  into  action.  It  seems  clear  that  a 
better  job  of  planning  can  be  done  through  the  use  of  an  analogous 
hierarchical  planning  system  similar  to  that  employed  in  large 
industrial  job  shops. 

The  key  to  devising  a  good  hierarchical  planning  system  is  to 
develop  ways  of  forecasting  demands  with  the  proper  degree  of 
aggregation  at  each  level  of  the  hierarchy  and  to  employ  decision 
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aiding  models  appropriate  for  each  level.  A  model  is  used  not 
only  for  specific  decisions,  but  also  as  a  means  of  testing  higher 
level  decisions  and  setting  the  conditions  and  constraints  for 
lower  level  decisions.  Moreover,  a  model  is  used  for  a  number  of 
activities:  answering  what  if  questions,  testing  boundary 
conditions,  diagnosing  problems,  and  experimenting  with 
alternative  solutions.  These  capabilities  are  more  important  than 
the  ability  to  work  out  in  detail  a  single,  specific  scenario  with 
(inappropriately)  presumed  certainty. 

In  the  job  shop  scheduling  world,  effective  ways  have  been 
developed  for  dealing  with  step  3  of  this  process  —  i.e.,  short 
term  scheduling.  The  general  method  incorporates  the  rules  and 
procedures  used  in  dispatching  and  control  (step  4)  into  a  flow 
model  that  simulates  the  movements  of  jobs  through  the  shop. 

We  believe  that  the  philosophy  of  hierarchical  planning  and 
control  we  have  outlined  here  holds  promise  for  mobilization 
planning.  The  research  that  we  propose  would  begin  by  defining 
the  planning  and  control  levels  appropriate  to  joint  operations 
planning.  Questions  to  be  answered  include:  what  levels  of  data 
aggregation  and  kinds  of  supporting  models  are  needed,  and  how  do 
planning  models  at  the  various  levels  interact?  Given  those 
results,  we  would  want  to  understand  how  the  actual  process  would 
change  if  supported  by  such  models.  What  would  be  the  benefits  in 
terms  of  information  that  would  be  available  to  decision  makers, 
and  how  robust  and  effective  would  the  resulting  plans  be? 
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This  hierarchical 

approach 

is  also 

consistent  with 

the 

recommendations  made 

earlier 

concerning 

system 

des ign. 

By 

breaking  the  planning  process  into 

modular 

pieces , 

it  will 

be 

possible  to  change  isolated  portions  while  leaving  the  others 
intact,  as  better  approaches  to  each  aspect  of  the  problem  are 
developed.  This  will  encourage  evolutionary  growth  and  is  much 
better  than  trying  to  design  a  monolithic  system  from  the  start, 
especially  when  the  design  may  be  based  on  a  poor  concept  of  how 
to  solve  the  overall  planning  problem. 
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